I think #57550 fixes the test failures here

Questions

• Should we ignore mountpoints that are not listed in $mountProviderArgs?
• Do we really need to pass $mountProviderArgs to the getMountsForPath() implementations? Currently, we do not use it.
• Salavtore changed an index share_with_file_target_index, does it mean that query that do not include file_target won't use the index now? Do we really want that?
• I move all the shared logic out of the getMountsForPath() implementations to their caller getUserMountsFromProviderByPath(). Is it a good idea? I don't see in which mount provider we would not do the same.

Salavtore changed an index share_with_file_target_index, does it mean that query that do not include file_target won't use the index now? Do we really want that?

We probably want to also keep the old index

Should we ignore mountpoints that are not listed in $mountProviderArgs?

Returning "to much" should be harmless

Do we really need to pass $mountProviderArgs to the getMountsForPath() implementations? Currently, we do not use it.

It's the part that has the actual "real" data about what mounts to setup, $path is "just" the path for which the setup was requested, not the path for which mounts are expected.

It would also be better for performance for mount providers to use the provided CacheEntry (though weaving that into the logic might be non-trivial)

I move all the shared logic out of the getMountsForPath() implementations to their caller getUserMountsFromProviderByPath(). Is it a good idea? I don't see in which mount provider we would not do the same.

"All mount provider do the same" and "the way they do it should be part of the api" are two different things that I think shouldn't be conflated.

Returning "to much" should be harmless

If we return too much, should we then register those missing mounts?

If we return too much, should we then register those missing mounts?

Probably, determining which of the extra ones are not registered already without extra cost might be tricky though.

Probably, determining which of the extra ones are not registered already without extra cost might be tricky though.

Well, we have the list of registered mount points in $mountProviderArgs (A), and the list of mount point from the provider perspective (B). So anything that is in B and not in A should be registered, no?

Well, we have the list of registered mount points in $mountProviderArgs (A), and the list of mount point from the provider perspective (B). So anything that is in B and not in A should be registered, no?

Providers could return mounts that are registered, just not requested.

• Create issue about registering extra mount providers and removing missing ones
• Create issue about share provider optimisations
  • Use the $mountProviderArgs instead of joining filecache
  • Now that we join the direct user share, we don't need the group, talk room, deck board loop to check for membership? But when is the user share created or deleted?
  • We can use the $mountProviderArgs[*]->mountInfo->getMountPoint() instead of doing a LIKE ${path}_%